The Unified Extensible Firmware Interface Forum (the “UEFI Forum”) is an alliance between several leading technology companies to modernize the booting process by use of a new protocol, the Unified Extensible Firmware Interface (UEFI) protocol. The UEFI Forum has published several versions of the UEFI protocol, the latest being version 2.3 on May 9, 2009.
Many microchip manufactures provide their customers with Customer Reference Boards (CRBs) as platforms to allow their customers to evaluate microchips (or “chips”) supplied by the chip manufacturer (also referred to as a “silicon vendor” or SV) for their specific applications. These manufacturer-provided platforms may include other hardware, software, or embedded firmware components, some of which may be tailored to a particular application of the customer. Customers of the microchip manufacturer are entitled to install the platform on one or more systems/devices (e.g., servers, personal computers, etc.) in order to evaluate the chip for their application. The embedded firmware in CRBs (also known as platform firmware) may include one or more Unified Extensible Firmware Interface (UEFI) component, each performing as a programming interface between the operating system (OS) of the system and the embedded firmware of the platform. The UEFI component also performs the function of platform initialization.
The Platform Initialization Working Group (PIWG) of the UEFI Forum provides specifications that are intended to promote interoperability between firmware components provided by various entities, such as silicon vendors and firmware vendors. These specifications provide a common internal framework for developers of hardware components and platform drivers.
A challenge of using UEFI arises from the large amount of effort required to perform customization of UEFI builds to suit the requirements of Original Equipment Manufacturers (OEMs) and others. Such customization includes revising a firmware product from a first device design to a related or derived design; for example, a board laid-out by the OEM that may incorporate hardware changes with respect to a CRB produced by a Silicon Vendor (SV).
Specifically, customizing source code in UEFI drivers which provide support for hardware components is a challenging task. Prior solutions build UEFI drivers into binary components from a collection of source code files. A utility (such as a ProcessDsc utility) parses a build script file (which may have a .dsc file extension and be referred to as a DSC file) to determine the list of drivers to be built as part of the binary build process. The DSC file contains an entry for each UEFI driver that should be built. This entry defines the path to a file with the .inf file extension (called an INF file). The INF file is one file among a collection of source code and header files that comprise the driver. The INF file contains, among other things, the list of source code files to be built in order to create the driver as a binary component. Typically, code that would need to access a hardware component, such as an Embedded Controller (EC), is written directly into the source code of each file where the support is needed. However, writing the hardware support code directly into the source code may create customization difficulties. In particular, customization difficulty may arise when a customer board uses a different hardware component than was used in the original CRB. Various approaches to address this difficulty have been proposed, each approach having certain drawbacks. Therefore, there is the need for a simpler manner of customizing source code in UEFI drivers.